React useActionState: En omfattande guide till modern formulärhantering

Detta tillvägagångssätt fungerar, men det har flera nackdelar:

• Standardkod (Boilerplate): Vi behöver tre separata useState-anrop för att hantera vad som konceptuellt är en enda process för formulärinskickning.
• Manuell state-hantering: Utvecklaren är ansvarig för att manuellt ställa in och återställa laddnings- och feltillstånd i rätt ordning inom ett try...catch...finally-block. Detta är repetitivt och felbenäget.
• Koppling: Logiken för att hantera resultatet av formulärinskickningen är tätt kopplad till komponentens renderingslogik.

Introduktion till useActionState: Ett paradigmskifte

useActionState är en React-hook som är specifikt utformad för att hantera tillståndet för en asynkron åtgärd, såsom en formulärinskickning. Den effektiviserar hela processen genom att koppla tillståndet direkt till resultatet av åtgärdsfunktionen.

Dess signatur är tydlig och koncis:

const [state, formAction] = useActionState(actionFn, initialState);

Låt oss bryta ner dess komponenter:

• actionFn(previousState, formData): Detta är din asynkrona funktion som utför arbetet (t.ex. anropar ett API). Den tar emot det föregående tillståndet och formulärdata som argument. Avgörande är att det som denna funktion returnerar blir det nya tillståndet.
• initialState: Detta är värdet på tillståndet innan åtgärden har utförts för första gången.
• state: Detta är det nuvarande tillståndet. Det innehåller initialState från början och uppdateras till returvärdet från din actionFn efter varje körning.
• formAction: Detta är en ny, inkapslad version av din åtgärdsfunktion. Du bör skicka denna funktion till <form>-elementets action-prop. React använder denna inkapslade funktion för att spåra åtgärdens väntande tillstånd.

Praktiskt exempel: Refaktorering med useActionState

Låt oss nu refaktorera vårt produktformulär med useActionState. Förbättringen är omedelbart uppenbar.

Först måste vi anpassa vår åtgärdslogik. Istället för att kasta fel bör åtgärden returnera ett state-objekt som beskriver resultatet.

Exempel: Det 'nya sättet' med useActionState

// Åtgärdsfunktionen, designad för att fungera med useActionState
const addProductAction = async (previousState, formData) => {
const productName = formData.get('productName');
await new Promise(resolve => setTimeout(resolve, 1500)); // Simulera nätverksfördröjning

if (!productName || productName.length < 3) {
return { message: 'Produktnamnet måste vara minst 3 tecken långt.', success: false };
}

console.log(`Produkten "${productName}" har lagts till.`);
// Vid lyckat resultat, returnera ett framgångsmeddelande.
return { message: `Lyckades lägga till "${productName}"`, success: true };
};

// Den refaktorerade komponenten
import { useActionState } from 'react';
// Notera: Vi kommer att lägga till useFormStatus i nästa avsnitt för att hantera det väntande tillståndet.

function NewProductForm() {
const initialState = { message: null, success: false };
const [state, formAction] = useActionState(addProductAction, initialState);

return (

Se hur mycket renare detta är! Vi har ersatt tre useState-hooks med en enda useActionState-hook. Komponentens ansvar är nu enbart att rendera UI:t baserat på `state`-objektet. All affärslogik är snyggt inkapslad i `addProductAction`-funktionen. Tillståndet uppdateras automatiskt baserat på vad åtgärden returnerar.

Men vänta, hur är det med det väntande tillståndet? Hur inaktiverar vi knappen medan formuläret skickas?

Hantera väntande tillstånd med useFormStatus

React tillhandahåller en kompletterande hook, useFormStatus, som är utformad för att lösa just detta problem. Den ger statusinformation för den senaste formulärinskickningen, men med en avgörande regel: den måste anropas från en komponent som renderas inuti det <form> vars status du vill spåra.

Detta uppmuntrar till en ren separation av ansvarsområden. Du skapar en komponent specifikt för UI-element som behöver vara medvetna om formulärets inskickningsstatus, som en skicka-knapp.

useFormStatus-hooken returnerar ett objekt med flera egenskaper, varav den viktigaste är `pending`.

const { pending, data, method, action } = useFormStatus();

• pending: En boolean som är `true` om det överordnade formuläret för närvarande skickas och `false` annars.
• data: Ett `FormData`-objekt som innehåller datan som skickas.
• method: En sträng som indikerar HTTP-metoden (`'get'` eller `'post'`).
• action: En referens till funktionen som skickades till formulärets `action`-prop.

Skapa en statusmedveten skicka-knapp

Låt oss skapa en dedikerad `SubmitButton`-komponent och integrera den i vårt formulär.

Exempel: SubmitButton-komponenten

import { useFormStatus } from 'react-dom';
// Notera: useFormStatus importeras från 'react-dom', inte 'react'.

function SubmitButton() {
const { pending } = useFormStatus();

return (

{pending ? 'Lägger till...' : 'Lägg till produkt'}

);
}

Nu kan vi uppdatera vår huvudformulärkomponent för att använda den.

Exempel: Det kompletta formuläret med useActionState och useFormStatus

import { useActionState } from 'react';
import { useFormStatus } from 'react-dom';

// ... (addProductAction-funktionen förblir densamma)

function SubmitButton() { /* ... som definierad ovan ... */ }

function CompleteProductForm() {
const initialState = { message: null, success: false };
const [state, formAction] = useActionState(addProductAction, initialState);

return (

Med denna struktur behöver `CompleteProductForm`-komponenten inte veta någonting om det väntande tillståndet. `SubmitButton` är helt fristående. Detta kompositionsmönster är otroligt kraftfullt för att bygga komplexa, underhållbara UI:n.

Kraften i progressiv förbättring

En av de mest djupgående fördelarna med detta nya åtgärdsbaserade tillvägagångssätt, särskilt när det används med Server Actions, är automatisk progressiv förbättring. Detta är ett viktigt koncept för att bygga applikationer för en global publik, där nätverksförhållanden kan vara opålitliga och användare kan ha äldre enheter eller inaktiverat JavaScript.

Så här fungerar det:

1. Utan JavaScript: Om en användares webbläsare inte kör klient-sidans JavaScript, fungerar `<form action={...}>` som ett standard HTML-formulär. Det gör en fullständig sidoförfrågan till servern. Om du använder ett ramverk som Next.js körs server-sidans åtgärd, och ramverket renderar om hela sidan med det nya tillståndet (t.ex. visar valideringsfelet). Applikationen är fullt funktionell, bara utan den SPA-liknande smidigheten.
2. Med JavaScript: När JavaScript-paketet laddas och React hydrerar sidan, körs samma `formAction` på klientsidan. Istället för en fullständig sidomladdning beter den sig som en vanlig fetch-förfrågan. Åtgärden anropas, tillståndet uppdateras och endast de nödvändiga delarna av komponenten renderas om.

Detta innebär att du skriver din formulärlogik en gång, och den fungerar sömlöst i båda scenarierna. Du bygger en robust, tillgänglig applikation som standard, vilket är en enorm vinst för användarupplevelsen över hela världen.

Avancerade mönster och användningsfall

1. Serveråtgärder vs. klientåtgärder

Den `actionFn` du skickar till useActionState kan vara en standard asynkron funktion på klientsidan (som i våra exempel) eller en Server Action (serveråtgärd). En Server Action är en funktion definierad på servern som kan anropas direkt från klientkomponenter. I ramverk som Next.js definierar du en genom att lägga till direktivet "use server"; högst upp i funktionens kropp.

• Klientåtgärder: Idealiska för mutationer som endast påverkar klient-sidans state eller anropar tredjeparts-API:er direkt från klienten.
• Serveråtgärder: Perfekta för mutationer som involverar en databas eller andra server-resurser. De förenklar din arkitektur genom att eliminera behovet av att manuellt skapa API-ändpunkter för varje mutation.

Det fina är att useActionState fungerar identiskt med båda. Du kan byta ut en klientåtgärd mot en serveråtgärd utan att ändra komponentkoden.

2. Optimistiska uppdateringar med `useOptimistic`

För en ännu mer responsiv känsla kan du kombinera useActionState med useOptimistic-hooken. En optimistisk uppdatering är när du uppdaterar UI:t omedelbart, i *antagandet* att den asynkrona åtgärden kommer att lyckas. Om den misslyckas återställer du UI:t till dess tidigare tillstånd.

Föreställ dig en sociala medier-app där du lägger till en kommentar. Optimistiskt skulle du visa den nya kommentaren i listan direkt medan förfrågan skickas till servern. useOptimistic är utformad för att fungera hand i hand med åtgärder för att göra detta mönster enkelt att implementera.

3. Återställa ett formulär vid lyckat resultat

Ett vanligt krav är att rensa formulärfält efter en lyckad inlämning. Det finns några sätt att uppnå detta med useActionState.

• Key-prop-tricket: Som visas i vårt `CompleteProductForm`-exempel kan du tilldela en unik `key` till ett inputfält eller hela formuläret. När nyckeln ändras kommer React att avmontera den gamla komponenten och montera en ny, vilket effektivt återställer dess tillstånd. Att binda nyckeln till en framgångsflagga (`key={state.success ? 'success' : 'initial'}`) är en enkel och effektiv metod.
• Kontrollerade komponenter: Du kan fortfarande använda kontrollerade komponenter om det behövs. Genom att hantera inputfältets värde med useState kan du anropa setter-funktionen för att rensa det inuti en useEffect som lyssnar efter framgångstillståndet från useActionState.

Vanliga fallgropar och bästa praxis

• Placering av useFormStatus: Kom ihåg att en komponent som anropar useFormStatus måste renderas som ett barn till `<form>`. Det fungerar inte om den är ett syskon eller en förälder.
• Serialiserbart state: När du använder Server Actions måste det state-objekt som returneras från din åtgärd vara serialiserbart. Det betyder att det inte kan innehålla funktioner, Symboler eller andra icke-serialiserbara värden. Håll dig till vanliga objekt, arrayer, strängar, nummer och booleans.
• Kasta inte fel i åtgärder: Istället för `throw new Error()`, bör din åtgärdsfunktion hantera fel på ett elegant sätt och returnera ett state-objekt som beskriver felet (t.ex. `{ success: false, message: 'Ett fel inträffade' }`). Detta säkerställer att tillståndet alltid uppdateras förutsägbart.
• Definiera en tydlig state-form: Etablera en konsekvent struktur för ditt state-objekt från början. En form som `{ data: T | null, message: string | null, success: boolean, errors: Record | null }` kan täcka många användningsfall.

useActionState vs. useReducer: En snabb jämförelse

Vid första anblicken kan useActionState verka likna useReducer, eftersom båda involverar uppdatering av state baserat på ett tidigare tillstånd. De tjänar dock olika syften.

• useReducer är en generell hook för att hantera komplexa tillståndsövergångar på klientsidan. Den utlöses genom att skicka (dispatcha) åtgärder och är idealisk för state-logik som har många möjliga, synkrona tillståndsändringar (t.ex. en komplex flerstegsguide).
• useActionState är en specialiserad hook utformad för state som ändras som svar på en enda, vanligtvis asynkron åtgärd. Dess primära roll är att integrera med HTML-formulär, Server Actions och Reacts funktioner för samtidig rendering som väntande tillståndsövergångar.

Slutsatsen: För formulärinskickningar och asynkrona operationer kopplade till formulär är useActionState det moderna, ändamålsenliga verktyget. För andra komplexa, klient-sidans state-maskiner förblir useReducer ett utmärkt val.

Slutsats: Omfamna framtiden för React-formulär

useActionState-hooken är mer än bara ett nytt API; den representerar en fundamental förändring mot ett mer robust, deklarativt och användarcentrerat sätt att hantera formulär och datamutationer i React. Genom att anamma den får du:

• Minskad standardkod: En enda hook ersätter flera useState-anrop och manuell state-orkestrering.
• Integrerade väntande tillstånd: Hantera laddnings-UI:n sömlöst med den kompletterande useFormStatus-hooken.
• Inbyggd progressiv förbättring: Skriv kod som fungerar med eller utan JavaScript, vilket säkerställer tillgänglighet och robusthet för alla användare.
• Förenklad serverkommunikation: En naturlig passform för Server Actions, vilket effektiviserar fullstack-utvecklingsupplevelsen.

När du påbörjar nya projekt eller refaktorerar befintliga, överväg att använda useActionState. Det kommer inte bara att förbättra din utvecklarupplevelse genom att göra din kod renare och mer förutsägbar, utan också ge dig möjlighet att bygga applikationer av högre kvalitet som är snabbare, mer robusta och tillgängliga för en mångsidig global publik.